Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@crates/taskito-core/src/storage/postgres/mod.rs`:
- Around line 127-129: The loop calling common_migrations::backfill_statements()
currently calls migration_alter(&mut conn, sql) which swallows errors; change
this so backfill failures are propagated instead of only logged: update
migration_alter to return a Result (or use an existing fallible variant), and in
the loop check its Result and return Err (or propagate with ?) including the SQL
and underlying error if any; ensure the enclosing function's signature returns
Result so failures abort startup/migration rather than being ignored.

In `@crates/taskito-core/src/storage/sqlite/mod.rs`:
- Around line 118-120: The backfill loop currently calls migration_alter(&mut
conn, sql) and swallows failures; change this to fail fast by checking
migration_alter's result and returning or propagating an error (or panicking)
when it fails so startup doesn't continue with bad data. Specifically, in the
loop over common_migrations::backfill_statements() in mod.rs, replace the blind
call to migration_alter with error handling that inspects its return (or update
migration_alter to return a Result if it doesn't) and propagate a failure (e.g.,
return Err(...) from the surrounding init function or call panic!) when
migration_alter indicates an error so has_deps/backfill never silently fails.

In `@dashboard/src/components/layout/last-refreshed.tsx`:
- Around line 28-32: The scheduled timeout in schedule() currently uses coarse
fixed bucket durations and can let labels stay stale; replace the fixed delay
calculation with a delay that aligns to the next label boundary based on age: if
age < 60_000 use 1000 - (age % 1000), else if age < 3_600_000 use 60_000 - (age
% 60_000), otherwise use 3_600_000 - (age % 3_600_000). Update the id =
setTimeout(...) call in the same schedule() block so setTick and the recursive
schedule() run when the next label change actually occurs.

In `@py_src/taskito/app.py`:
- Around line 695-708: The batch-builder currently builds per-job option arrays
from mixed scalar or list inputs (delay_list, metadata_list, notes_list,
expires_list, result_ttl_list, unique_keys, idempotency_keys) without verifying
that any provided lists match the number of jobs (count or len(args_list)),
which allows mismatched lengths to produce confusing downstream errors (e.g., in
_inner.enqueue_batch). Before constructing notes_encoded and the other _src
lists, validate each provided per-job list (those ending with _list or the
unique_keys/idempotency_keys lists) has length == count; if any mismatch raise a
clear ValueError indicating which parameter has the wrong length and what the
expected length (count) is so callers get immediate, actionable feedback.

In `@py_src/taskito/mixins/decorators.py`:
- Around line 156-158: The middleware filtering in _get_middleware_chain
currently only checks mw.name, so dashboard disables that use class-path keys
don't match unnamed middleware; convert the incoming disabled iterable to a set
of strings and when filtering the chain check both getattr(mw, "name", "") and
the middleware class path (mw.__class__.__module__ + "." +
mw.__class__.__name__) against that set, removing any mw that matches either key
so unnamed middleware can be disabled by class path as admin discovery does.

In `@py_src/taskito/proxies/reconstruct.py`:
- Around line 30-35: The current shared ThreadPoolExecutor (_RECONSTRUCT_POOL)
cannot stop already-running reconstruction work because
Future.result(timeout=...) only stops waiting and future.cancel() won't kill
started threads; change the reconstruction to run in an isolated process that
can be terminated on timeout: replace the ThreadPoolExecutor-based
submit+future.result(timeout=...) usage with a per-task multiprocessing.Process
(or spawn via multiprocessing.get_context("spawn")), start the process for the
reconstruction function, join with the desired timeout, and if the join timed
out call process.terminate() and process.join() to free the worker; ensure the
reconstruction caller checks for a terminated process and raises/returns a
timeout error. Reference symbols: _RECONSTRUCT_POOL, ThreadPoolExecutor,
Future.result, future.cancel.

In `@tests/core/test_middleware_chain_cache.py`:
- Around line 16-33: The test intermittently fails because the middleware-chain
cache TTL (_MW_CHAIN_TTL) can expire during the loop; to fix, in
test_middleware_chain_caches_disable_reads set or monkeypatch the TTL or the
module's monotonic time so the TTL cannot elapse during the 50 iterations (e.g.,
assign a large value to Queue._MW_CHAIN_TTL or the module-level _MW_CHAIN_TTL,
or patch time.monotonic to a fixed value) before creating the Queue and running
the loop, then restore the original value if needed; target symbols:
test_middleware_chain_caches_disable_reads, Queue, _get_middleware_chain, and
_MW_CHAIN_TTL.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@py_src/taskito/dashboard/handlers/middleware.py`:
- Around line 50-53: The PUT registration check currently builds names from
mw.name which may differ from the canonical keys; update the check to use
middleware_key(mw) instead: when constructing names from base_chain (from
queue._global_middleware and queue._task_middleware.get(task_name, [])) call
middleware_key on each middleware and compare mw_name against that set, leaving
the _NotFound raising logic (and variables mw_name, task_name, base_chain)
unchanged so valid middleware keys are not incorrectly 404ed.